The approaches described in this section could be pursued, but are not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, the approaches described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.
After a computer program has been released for sale to the public, and consumers have purchased and installed the program on their computer, updates to the computer program may become available. Such updates may fix errors in the previously released program, or add enhanced features that were not present in the previously released program. Such updates are often supplied to consumers in the form of another customized program that applies changes to the binary code of the previously released program. Often, the changes applied to the binary code do not completely replace the binary code, but only alter portions thereof. The process of applying updates to portions of a previously released program, instead of replacing the program entirely, is called “patching,” and the updates that are applied are called “patches.”
Separate groups or organizations, which do not necessarily coordinate their efforts with each other, may author different patches that target the same files of a computer program. For example, one group may author one patch that, when applied, replaces previous versions of files “A” and “B” with different versions of those files, and another group may author another patch that, when applied, replaces versions of files “B” and “C” with different versions of those files. If both patches are applied to the target files, then, unless the later-applied patch duplicates the effects of the earlier-applied patch relative to file “B” (which is unlikely), the application of the later-applied patch will obliterate the effects of the application of the earlier-applied patch relative to file “B.” This is an undesirable outcome.
The problem described above becomes more complicated when the files targeted by the patches are nested within archives, which may be nested within yet other archives, at any number of levels. For example, it is common for multiple Java class files to be nested within a Java Archive (JAR) file. Several JAR files may be nested within a Web Archive (WAR) file. Several WAR files may be nested within an Enterprise Archive (EAR) file. One patch, when applied, might replace multiple Java class files that are distributed among different JAR files. Another patch, when applied, might replace an entire WAR file. If the WAR file contains a JAR file that contains a particular Java class file that is targeted by the former patch, and if the latter patch is applied after the former patch is applied, then the application of the latter patch will obliterate the effects of the application of the former patch relative to the particular Java class file.